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REMARKS 

Claims 1 through 24 are pending in this application. 

I. REJECTION OF CLAIMS (35 U.S.C. § 103) 

According to MPEP 706.02(j), the following establishes a prima facie case of obviousness 
under 35 U.S.C. §103: 

To establish a prima facie case of obviousness, three basic criteria 
must be met. First, there must be some suggestion or motivation, 
either in the references themselves or in the knowledge generally 
available to one of ordinary skill in the art, to modify the reference or 
to combine reference teachings. Second, there must be a reasonable 
expectation of success. Finally, the prior art reference (or references 
when combined) must teach or suggest all the claim limitations. The 
teaching or suggestion to make the claimed combination and the 
reasonable expectation of success must both be found in the prior art 
and not based on applicant's disclosure. In re Vaeck, 947 F.2d 488, 20 
USPQ2d 1438 (Fed. Cir. 1991). 

Claims 1-24 are rejected under 35 U.S.C. 103(a) as being unpatentable over Jenkins et al. 
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(6,002,868) (hereinafter Jenkins) in view of Philyaw et al. (6,704,864) (hereinafter Philyaw). The 
Applicant respectfully traverses. 

1. Claims 1, 8 and 17. 

a. Jenkins in view of Philyaw fail to teach or suggest the web server including a 
device driver error handler that performs diagnosis from the computer's monitoring unit. 

The Examiner admits that Jenkins explicitly does not disclose that central monitoring station 
is a web server. However, the Examiner argues that the web server comprising driver handling * 
programs, storing, comparing, testing, updating, and searching device driver information are well 
known in the art and that Philyaw, for example, web server (col 4, lines 43-48) comprising driver 
handling programs (col 26, lines 10-35), storing (col 26, lines 10-35), comparing (col 26, lines 10- 
35), testing (col 26, lines 10-35), updating (col 26, lines 10-35), and searching device driver 
information (col 26, lines 10-35). Therefore, the Examiner states that it would have been obvious 
to one of ordinary skill in the art at the time invention is made to combine the teachings of Philyaw 
and Jenkins because it would provide an architecture for automatic configuring a software of a 
computer system which can be executed remotely on the client machine. 

Respectfully, the Examiner is extrapolating from Philyaw rather than what it actually 
teaches. According to MPEP §706.02(j) the prior art reference (or references when combined) must 
teach or suggest all the claim limitations. There must be an actual teaching rather than a conclusion. 
Philyaw is still not teaching or suggesting the claimed invention as there is no actual teaching of the 
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device driver error handling program on the web server performing diagnosis of the device driver. 
The Examiner mentions that the web server is storing, comparing, testing, updating, and searching 
device driver information, but these individual procedures cannot be combined to form what the 
Examiner wants them to be. Basically, Philyaw only teaches of updating the device driver, there is 
no teaching of diagnosing the device driver and Jenkins also does not make such a teaching or 
suggestion. The Applicant sincerely suggests that the Examiner remove such a rejection as when 
appealed, such a rejection would not be held up based on current law. 

Executing remotely by a network as mentioned in Jenkins is not the same as claimed where 
the web server includes the diagnostics. According to the teaching of Jenkins, then the web server 
of Philyaw would remotely execute the programs on the computer being tested which is not what the 
claim states as there is still no teaching of the diagnosis being actually on the web server. 

Moreover, "Combining prior art references without evidence of such a suggestion, teaching, 
or motivation simply takes the inventor's disclosure as a blueprint for piecing together the prior art 
to defeat patentability. In re Dembiczak, 175 F.3d 994, 50 USPQ.2d 1614 (Fed. Cir. 1999). The 
Examiner states that it would have been obvious to one of ordinary skill in the art at the time 
invention is made to combine the teachings of Philyaw and Jenkins because it would provide an 
architecture for automatic configuring a software of a computer system which can be executed 
remotely on the client machine. However, according to MPEP 706.020), the teaching or suggestion • 
to make the claimed combination and the reasonable expectation of success must both be found in 
the prior art and not based on applicant's disclosure. In re Vaeck, 947 F.2d 488, 20 USPQ2d 1438 
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(Fed. Cir. 1991). There was no suggestion or teaching as to remotely handling the driver error on 
the web site by Jenkins or Philyaw. 

Therefore, the Examiner should remove such a rejection on the claimed invention. 

b. Jenkins (and also the combination of Jenkins and Philyaw) fails to teach or suggest 
the use of the device driver information in a diagnosis. 

The device driver information being used for diagnosis is not actually taught or suggested. 
Unlike Jenkins, the present invention can correct problems such as registry problems with device 
driver information or other problems not directly related to the device driver file itself as the present 
invention claims the device driver information. 

c. Jenkins (and also the combination of Jenkins and Philyaw) fails to teach or suggest 
the monitoring unit outputting a diagnostic message to said computer when said device driver error 
occurs. 

Concerning the device driver error, the Examiner responds in paper no. 20041208 that 
Jenkins teaches outputting a diagnosing message to said computer when said device driver errors 
occur (col 6, lines 23-67, col 7, lines 45-55 and col 8, lines 26-53). 

However, looking at the cited portions of Jenkins describes tests for errors of actual devices 
rather than the device drivers that drive the actual devices. For example, on col. 7, lines 45-55, it 
is the hardware devices that are identified and tested. There is no mention of errors with the device 

Page 5 of 14 



PATENT 
P56321 

drives, but rather the hardware devices. 

Jenkins mentions that the error handler module 218 is a depository of all error information 
(which tests are valid) gathered by the diagnostic libraries 202 when the DLs are executed. 

Col. 9, lines 28-38 of Jenkins mentions that the diagnostic library 202 is a group of 
independent diagnostic modules 234-268. Each diagnostic module 234-268 targets a specific piece 
of hardware or software process. In general, the diagnostic modules 234-268 are responsible for: 1) 
identifying all of the hardware devices in the computer system C; 2) specifying valid tests for the 
hardware devices; 3) relaying all information needed by the front end module 210 to display and 
allow selection of diagnostic tests; 4) specifying default test parameters; 5) executing the diagnostic 
test(s); and 6) relaying test status and errors to the front end 210 and table 3 details some of the 
diagnostic library components. As mentioned in col. 9, there is a list of hardware devices or software 
processes. However, looking at the software processes, the include ProcDev and WavePlay and 
WavRec, however these are related only to the process itself of playing the wave file for instance, 
but not of the actual driver that drives a device. The WavePlay is only related to the executable file 
playing the wave file, but not for example the actual driver for the sound card. 

Jenkins only mention even remotely related to device drivers is mentioned concerning the 
virtual device driver VxD 206, but its error is not taught as being outputted as a diagnostic message 
to the computer. Moreover, the virtual device drivers do not drive an actual device since they are 
virtual rather than actual device drivers. 

d. The combination of references fail to teach or suggest storing standard information 
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of said device driver to accommodate diagnosis on the web server while the monitoring unit on the 
first computer monitors the operation state of the device driver. 

The Examiner argues that Jenkins teaches of diagnosing error information on the computer 
itself, but that Philyaw show how it could be done remotely on the web server. 

However, never does Philyaw specifically teach how one of ordinary skill in the art would 
do such error handling on the web server. Philyaw is only for device driver updating which does not 
help in problems such as if the registry is incorrect. There still needs to be a teaching that the device 
driver information is used on the web server to diagnose an error concerning the device driver. 

The Philyaw only deals with the device drivers being update rather than the information of 
the device drivers as when it is standard and the information extracted from the computer being 
diagnosed. 

e. The combination of Jenkins and Philyaw fails to teach or suggest comparing 
standard driver information with the device driver information. The Examiner argues that col. 8, 
lines 26-53 teaches or suggests this, but this section only mentions storage of error information and 
storage of corrective actions. The errors for devices are mentioned and not the device driver 
information that is compared. 

f. There is also no teaching in the references about the monitoring unit being in the 
computer while the web server has the driver error handling program. The Examiner states that 
Jenkins has both and then Philyaw modifies. However, never does Philyaw give a teaching that the 
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monitor program is to be on the computer and the error handler on the web server, as such distinction 
is never taught but rather speculated using the present invention as a blue print. 



2. Claims 2, 12, 18 and 19. 

As shown above, the web server is not taught by the references to perform a diagnosis of the 
error. Moreover, as claimed in claim 2 for example, the web server does not entail such features of 
the first through fourth portion. The Examiner argues that Jenkins teaches that such sections are 
taught and that Philyaw can modify Jenkins as to do such functions. However, Philyaw's distinct 
functions checking and updating cannot be extrapolated to actually performing the diagnosis of the 
present invention. The Examiner is improperly piecing together portions and functions to form a 
rejection, but is failing to show an actual teaching as there is no actual teaching of such, but is 
actually based on conclusion. Nowhere in even the arguments of the examiner is there an actual 
teaching mentioned, but rather a statement that such is known in the art and Philyaw discloses certain 
function which could be used to such a feature. However, this argument fails to provide an actual . 
teaching. 

Furthermore, Jenkins also does not even teach of the individual elements as claimed since 
the error handling module concerns the errors rather than the driver information as claimed in the 
present invention. The Examiner's cited portions of the references again only relate to storing of the 
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errors rather than the device driver information. 

3. Claims 3, 9, 10, and 20. 

a. The combination of references fail to teach or suggest a differentiation when an 
error is correctable or not. 

In the response to the arguments, the examiner merely reiterates that col. 8, lines 26-53 and 
col. 4, lines 36-67 of Jenkins discloses such a feature. The Examiner failed to provide any sort of 
explanation or support for his argument other than repeating the same portions which clearly make 
no such distinction, rather the Examiner is focusing in on only the display aspect of the diagnosing 
result and failing to take into account the entire text of the claim. 

Col. 4 only mentions the error handler module and col. 8 mentions of displaying the error and 
recommendation actions, but both col. 4 and 8 fail to differentiate when an error is correctable or not 
because the claim states the recommendation of correcting the error is when the error is 
automatically uncorrectable and displaying an error correction result after automatically correcting 
the error. Jenkins only states that the corrective action is displayed, but that it is done when there 
is no automatic fix. 

Moreover, Jenkins, unlike the present invention fails to teach the display of the result after * 
fixing the error as Jenkins only mentions about error display and recommended actions. 

b. The combination of references also fail to teach or suggest of automatic correction 
of the error as also related to the display. Jenkins only states the recommended action module 220 
contains information on what to do to fix an error, but does not execute the correction automatically 
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and the automatic correction is not related to the type of display. 

4. Claims 5, and 14 

The combination of references fail to teach or suggest of actually not being able to 
manipulate the monitoring file. 

The Examiner states that such files in Jenkins are not accessible since they are binary and 
data accessed by executables. However, the claim states a user of said computer not being able to 
manipulate. Technically, a user on the computer of Jenkins can still access such files and still 
manipulate. There is no actual limitation as even such files can technically be accessed and 
manipulated. There is no actual teaching that such is not possible, but rather the Examiner is 
assuming since such file not commonly manipulated by the user, but technically it is possible and 
therefore, such a teaching is not made by Jenkins. 

5. Claims 7, 16, and 22. 

The combination of references do not state that hardware error is automatically uncorrectable. 
Col. 7, lines 45-55 cited by the Examiner only state that hardware devices are identified and then 
there is specification of valid tests for each of the hardware devices. However, nowhere is this 
stating that hardware error is automatically uncorrectable. The Examiner needs to provide a teaching 
which again, the Examiner has failed to provide. Rather, in the response to the arguments on page 
1 1 , the Examiner makes a conclusory remark that a distinction is not made. Clearly, the Examiner 
has failed to provide a prima facie case of obviousness as all the features of the claimed invention 
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are not taught or suggested. The entire wording of the claims must be examined and not just a 
summary of the claim. 

6. Claim 23. 

The references fail to teach or suggest recommending a correction of the error when the error 
is automatically correctable and when said first computer opted no correction in said step of 
prompting a response from said first computer; executing no correction of the error when the 
recommendation is not accepted; and correcting the error when the recommendation is accepted. 

All features as arranged in the claim are not taught or suggested. The Examiner states that 
col. 8, lines 26-54 of Jenkins discloses a correction of the error when the error is automatically 
correctable and when said first computer opted no correction in said step of prompting a response 
from said first computer; executing no correction of the error when the recommendation is not 
accepted computer; and correcting the error when the recommendation is accepted computer. 

However, lines 26-54 of col. 8 concern the error handling module 218 and the front end 
module 210 but never are the claim features taught or suggested. The module 220 has possible 
recommendations and the front end module 210 displays the information, allows selection of 
specification of diagnostic test, but this selection of the diagnostic test does not specifically disclose 
a condition of being automatically correctable for when the recommendation of the correction error 
is made. Such limitation on the selection is never taught or suggested. The different distinctions 
of the recommendation is never taught by merely a prompt for response as no actual detail of when 
such prompt is made is ever given in Jenkins. The Examiner is improperly concluding based on the 
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Examiner's knowledge rather than using the teaching of the references. 
II. 37 C.F.R. §1.104 

The Applicants respectfully believe that the final Office action mailed on 4 January 2005 
(Paper No. 20041208) is a premature final Office action because in the previous response to paper 
number 9, the Applicant had asked the Examiner that further clarification by Examiner would be 
very helpful to the Applicant. Specifically and respectfully, the response stated that the Examiner 
must provide the completeness in the rejection under 37 C.F.R. §1.1 04(b) and (c) in formulating the 
rejection. As mentioned in 37CFR §1.104 (c)(2), "When a reference is complex or shows or 
describes inventions other than that claimed by the applicant, the particular part relied on must be 
designated as nearly as practicable." Concerning certain rejections, a string of passages were quoted 
without any particular reference to the particular parts being relied on. The particular parts relied 
upon were not mentioned and therefore it makes it difficult for the Applicant to respond to the 
Examiner's rejection. Quoting large portions of the text does not always take the place of showing 
the particular part especially when it is not entirely clear what particular parts are being referenced 
from the body of text quoted. 

The particular parts relied upon were not always mentioned and therefore it makes it difficult 
for the Applicant to respond to the Examiner's rejection. As seen throughout the office action of the 
Examiner, only general portions of the specification were mentioned without differentiating what 
particular parts are being relied upon. For example pages of a reference such as col. 8, lines 26-53 
and col. 4 lines 35-67 were stated for a particular part, but looking at over 50 lines of text it is 
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difficult to discern the particular part being relied upon. 

The Applicant asked the Examiner in the previous office action response and the Examiner 
has failed to provide such information and now the Applicant asks again and since such was not 
provided, the finality of the rejection should be removed. 

As mentioned in MPEP §706.07, " Before final rejection is in order a clear issue should be 
developed between the examiner and applicant. To bring the prosecution to as speedy conclusion as 
possible and at the same time to deal justly by both the applicant and the public... present practice 
does not sanction hasty and ill-considered final rejections. The applicant who is seeking to define 
his or her invention in claims that will give him or her the patent protection to which he or she is 
justly entitled should receive the cooperation of the examiner to that end, and not be prematurely cut 
off in the prosecution of his or her application. . . .The examiner should never lose sight of the fact that 
in every case the applicant is entitled to a full and fair hearing, and that a clear issue between 
applicant and examiner should be developed, if possible, before appeal." 

The Applicant would greatly appreciate the Examiner's cooperation on this regard in order 
to provide a full an fair hearing for the Applicant. 
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No fee is incurred by this Response. Should there be a deficiency in payment, or should other 



fees be incurred, the Commissioner is authorized to charge Deposit Account No. 02-4943 of 



Applicant's undersigned attorney in the amount of such fees. 



Respectfully submitted, 




Attorney for the Applicant 
Registration No. 27,774 

1522 "K" Street, N.W., Suite 300 
Washington, D.C. 20005 
(202) 408-9040 

Folio: P56321 
Date: 3/31/05 
I.D.: REB/SS 



Page 14 of 14 



